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ABSTRACT 



Two programming paradigms, logic programming and 
functional programming, are discussed in detail with 
emphasis on the particular advantages and disadvantages of 
each paradigm. 

The integration of these two programming paradigms is 
explored based on the notion that declarative sorts of 
knowledge (facts and logical relationships) should be 
expressed in a declarative way, and that procedural sorts of 
knowledge (manipulation, control, and utilization of 
knowledge) should be expressed in a procedural way. Toward 
this end, the conceptual framework for an integrated 
language is established, and the basic features of the 
language are outlined. 
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I 



INTRODUCTION 



A. PROGRAMMING LANGUAGE DESIGN 

Programming language design represents both an effort to 
provide the necessary interface with the hardware of the 
computer and an effort to better capture the ideas of the 
programmer. As higher order programming languages evolve^ a 
key factor in each language designed is the level of ab- 
straction afforded the programmer. Current conventional 
languages have removed the programmer from the hardware 
level of the machine. For instance^ instead of being con- 
cerned with which registers to use^ the programmer can be 
more concerned with solving the problem at hand. For 
certain classes of problems^ this higher level of abstrac- 
tion increases the semantic power of the language and better 
captures the problem solving concepts of the programmer. 
The evolution of programming language design has resulted in 
solutions to a broader class of problems and even new 
approaches toward the solution of presently unsolved 
problems. 

B. PROBLEM COMPLEXITY 

The features of the language are the tools with which 
the programmer tackles a host of complex problems. As the 
problem complexity increases, the manner in which- one works 
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toward a solution can be affected by the tool or tools 
available. Consider the analogy of an automobile mechanic 
working on an automobile engine; a simple tune-up, 
adjustment, or small part replacement can be performed with 
simple handtools and devices. However, if the problem is 
more complex, say involving the cylinders, camshaft, or 
drive train, then the mechanic cannot solve such problems 
with simple tools. The solution now requires more advanced 
tools like hydraulic lifts, pneumatic tools, and precision 
instruments. In fact, without more advanced tools, the job, 
if still possible, is solved through improvisation with the 
simpler tools and results in a less efficient and imprecise 
solution . 

C. SAPIR-WHORF HYPOTHESIS 

Similarly, the features of the programming language can 
effect the manner in which the programmer approaches the 
solution to a particular problem. This can be considered an 
application of the controversial Sapir-Whorf hypothesis 
which originated in linguistic theory CRef. 11. Assuming 
this hypothesis, the programmer attempting to solve complex 
problems with a limited programming language cannot realize 
his full problem solving potential and must improvise with 
the available language features to work toward an acceptable 
solution . 
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NON-CONVENTIONAL PROGRAMMING LANGUAGES 



Conventional programming languages do not offer the 
programmer a very high level of abstraction, have a 
restrictive ^word-at-a-time” CRef. 5: p. 404] programming 
style, and result in what Backus refers to as an 
••intellectual bottleneck** CRef • 3] • The sequential nature 
of these imperative languages, through use of assignment 
statements to alter memory, results in a von Neumann **mind 
set**, and places limitations upon the level of abstraction 
available to the programmer. Efforts to provide more 
semantic power to these languages has resulted in the 
development of the Ada CRef. 6] programming language. This 
very large and very complex language provides increased 
semantic power at the coat of simplicity, clarity of 
understanding, and programmer mastery of his tool CRef. 63. 

Non-conventional programming languages, on the other 
hand, offer a break from the von Neumann mind set and help 
the programmer approach and solve problems from new 
perspectives. Such non-conventional programming languages 
are illustrated by PROLOG CRef. 2,7], Backus' FP language 
CRef. 3], and SMALLTALK CRef. 43. Each of these languages 
represents an implementation of a particular programming 
language paradigm, namely, logic programming, functional 
programming (applicative programming with emphasis on 
functions as arguments), and object-oriented programming, 
respectively. Issues such as semantics, computational 
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power, perallellsM, side effects, flexibility, simulation, 
and knowledge representation exemplify some of the basis for 
development of language design In each of these programming 
paradigms . 

E. RESEARCH FOCUS 

With these Issues In mind, two programming paradigms, 
logic programming and functional programming, are discussed 
In detail. The emphasis of the discussion will be in terms 
of the particular advantages or disadvantages of each 
programming paradigm, often exemplified by the PROLOG or 
“pure" LISP Implementation. The focus of this study will be 
toward the development of a theoretical foundation for the 
design of an integrated programming language which, of 
course, maximizes the advantages of both paradigms and 
minimizes their disadvantages. Such an integrated language 
should broaden the scope of the programmer's problem solving 
capability by providing a tool that is both semantically and 
computationally powerful, and offers improved control 
characteristics . 
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II. LOGIC PROGRAMMING 



A. BACKGROUND 

The foundation for the development of a programming 
language baaed upon the rigors of predicate logic aeema to 
have grown out of early attempts to automate theorem proving 
[Ref. 5, 7, 113 and haa subsequently been bolstered by the 
demands of the artificial intelligence <AI) community in an 
effort to live up to their rather ambitious name. Hewitt's 
PLANNER [Ref. 113/ a language designed for theorem proving 
and robot model manipulation, utilized such concepts as 
backtracking and a database of assertions CRef. 73, which 
would later be embraced by the designers of PROLOG. The 
theoretical foundation for programming in logic, however, is 
probably beat described in Kowalski^a work CRef. S, 9, 103 . 
In particular, his paper in the Communications of the ACM 
CRef. 83, though concerned with predicate logic as a tool 
for algorithm analysis, introduces the separation of the 
logic and control components of an algorithm and strongly 
suggests the usefulness of this concept in programming 
languages. Additionally, Kowalski defines the semantics of 
predicate logic programs CRef. 93 , in a collaboration with 
van Emden, regarding proof theory and model theory. 
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A logic program consists of the explicit use of Horn 
clauses in the process of goal satisfaction. Both Horn 
clauses and the process of goal satisfaction are described 
below. Additionally, the advantages and disadvantages 
afforded the programmer by using' logic programming are 
detailed . 

B. HORN CLAUSE 

A Horn clause is a subset of the full predicate logic 
system that is- quantif ier-free and contains at most one 
positive literal. It is the preferred logical formula in 
the expression of logic programs. Horn clauses can be 
represented by both the logical form, where means 

negation, and the standard convention, <head> <-- <body>, 
called a definite clause. The following four 

classifications of clauses are illustrated by both: 

1) Assertion (only one positive literal) 

B or B <-- 

2) Declaration (one positive literal and one or more 
negative literals) 

B V -A, V...V -A or B <-- A.,...,A 

1 n I n 

3) Denials (no positive literals) 

"A - V ... V ” A or A.,...,A 

1 n I n 

4) Contradiction (the empty clause) 

0 or <-- 
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C. GOAL SATISFACTION 



A logic program conaiata o£ a nunber o£ theae Horn 
clausea^ aa axioma, upon which the atteapted satia£action o£ 
a particular goal ia baaed CRe£« 121 • An important point 
here ia that theae axioma are user de£ined and baaically 
provide the ayatea interpreter with the facta required to 
determine whether a given goal ia aatiafiable. 

1 . Reaolution and Unification 

A logic programming interpreter attempts to solve a 
particular goal statement by resolving any aubgoala within 
the statement with the heads of definite clauaea of the 
logic program. Since the reaolution process ia one of proof 
by refutation^ a goal ia aatiafiable if the empty clause 
(contradiction) can be derived. During the derivation 
certain bindings for variables may be made which become the 
solution for the given goal statement [Ref. 12]. 

There are several algorithms CRef- 13^ 14] for 

performing such unifications, the foundation of which is 
described by Kowalski CRef. 9] and detailed by Hill CRef. 
15] , where he names the process LUSH (Linear reaolution with 
Unrestricted Selection for Horn clauaea) . 

The LUSH rule of inference takes a given goal 
statement A^,...,A^ and attempts to resolve a aubgoal 
with a definite clause within the logic program that 
contains an identical form of A^ aa the head of the clause. 
Recall that the actual form of the goal statement ia 
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-Aj^ V...V "A^, and that the subgoal being resolved is “A^. 
Since the head of the clause is the positive literal, the 
unification of the subgoal and the definite clause resolves 
the literal and replaces it with the body of the clause 
[Ref. 10, 16]. This derivation is possible, of course, only 
if some general substitution function, mapping variables to 
terms, makes the subgoal and the head of the definite clause 
identical CRef . 10] . 

2. Won-determinism 

Predicate logic is non-deterministic in that the 
unification process follows a pattern matching scheme for 
resolution of subgoals and more than one definite clause may 
have a head that will match CRef. 10, 12] . Therefore, a 
resolution procedure like LUSH requires a selection 
component and a search component CRef. 16] , where the 
selection component is the rule to determine the search 
apace, and the search component is the strategy whereby that 
apace la searched. This search space can be thought of as a 
tree with the goal statement as the root and descendant 
nodes determined by the selection component. The paths of 
this tree are then traversed according to a strategy given 
by the search component. 

Such a non-deterministic system, then, requires 
somewhat restrictive selection and search components because 
of the possibility of an infinite number of paths in the 
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aearch space or because o£ finite paths that do not lead to 
the empty clause CRef . 16] . 

3 . PROLOG Example 

The selection component of PROLOG provides a rule 
that always selects the leftmost literal CRef. 3, 163 . 
Therefore, the negative literals of a clause must be ordered 
and fixed, and only those search spaces (or developing 
trees) can be implemented CRef. 16]. The aearch component 
in PROLOG provides a depth-first strategy with the leftmost- 
descendant first (derived by the above selection rule) . The 
ordering of descendenta is determined by the ordering of the 
definite clauses within the logic program. 

Consider the following logic program (ignoring the 



structure of 


the 


clauses 


and 


the unifying substitutions) 


CRef. 123: 












(1) 


A <-- B, 


C 






(2) 


w 

A 

1 

1 

o 


E 






(3) 


B <-- F 








(4) 


C 








(5) 


D 




• 




(6) 


A 

1 

1 

o 








(7) 


F 






Given 


the 


goal statenent 


<-- Ap the aearch space for 



resolving this goal is depicted as a tree in Figure 2.1 
CRef. 12] . This aearch tree la an OR-tree whose nodes are 
possible goals that may occur during resolution of the goal 
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at.at.enent. Each edge of the tree la labeled by the Index to 
the particular clauae of the logic program (above) that was 
used In the resolution process based upon the selection 
component previously described. The search component 
progresses through the entire tree until either the empty 
clauae Is found or the entire tree Is searched CRef. 123. 
Although the unifying substitutions are Ignored here, those 
substitutions, made along a successful path, yield an answer 
for the goal statement. 



<-- A 
I 

(1) I 
I 

<-- B, C 
/\ 

/ \ 

<2> / \ (3) 

/ V 

/ \ 

<-- D, E, C < — F, C 

/\ 

/ \ 

(5) I (6) / \ (7) 

/ \ 

/ \ 
<-- E, C <-- G, C <-- C 

I 

(4) I 
I 

0 



Figure 2.1 Search Space Depicted as a Tree 



In order to avoid the redundancy of repeated 
aubgoala In the search tree, many PROLOG systems construct a 
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proof tree [Ref. 12] . A proof tree Is generated for each 
node In the search tree. It Is an AND-tree where the root 
is the original goal and the leaves are the corresponding 
subgoals of the search tree [Ref. 12] . The proof trees for 
nodes < - - D,E,C and < - - F,C are Illustrated in figure 2.2 



A 

/\ 

/ \ 

/ \ 

B \ 

/\ \ 

/ \ \ 

/ \ \ 
DEC 

(a) 

A 

/\ 

/ \ 

/ \ 

B \ 

I \ 

I \ 

I \ 

F C 

<b) 



Figure 2.2 Proof Trees 



During the resolution process. if a leaf cannot be 
unified or resolved with the head of another definite clause 
within the logic program. then a portion of the tree is 
erased. That portion is from the unresolvable leaf back to 
the most recent node that has not exhausted its potential 
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for Matching CRef. 123. This process Is called backtracking 
and the node at which backtracking stops is called a 
backtracking point. The search continues from the 
backtracking point pursuing the unsearched alternatives. A 
success requires that every path of the proof tree end with 
the empty clause CRef. 123 . 

For example, in Figure 2.2(a). the leaf D can be 
resolved with the empty clause. but the leaf E cannot, 
sincethere are no clauses within the logic program that have 
a head to match it. Therefore the system must backtrack to 
node B since an alternative choice within the search tree 
(see label (3). Figure 2.1) is still available. That choice 
la depicted by the proof tree in Figure 2.2(b). 

This backtracking is necessary because of the non- 
determiniatic characteristics of the resolution of subgoals. 
Yet it is easy to see that fairly large and complex programs 
would require considerable backtracking. 

D. ADVANTAGES 

Logic programming offers seductive advantages when 
dealing with certain classes of problems. Ideas of logic 
have matured for centuries and have a concise and 
universally understood semantics. For bodies of knowledge 
that can be represented in a logical form, logic programming 
offers a means to prove things about that body of knowledge 
TRef . 203 . 
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1 



Non "Procedural 



The notion of a non-procedural language ia one in 
which the features of the language allow the programmer to 
concentrate more on ••what” the program will do and not on 
•*how^’ it will be done [Ref. 5: p. 499] . The goal-directed 
nature of logic programming embodies this notion, in that 
the programmer expresses the facts, in clause form, which 
assert the existence of the desired result [Ref. 5: p. 500]. 
The construction of the desired result, then, is based upon 
the resolution process of the logic programming language and 
removes the burden of ••how*^ it will be done from the 
programmer . 

2 . Simple Semantics 

Much of the power behind the semantics of 
programming rests with the notions of truth and inference 
[Ref. 18] . Assertions within the logic program are accepted 
as truth, and the clauses within the program are facts that 
allow inferences to be made based upon those assertions. 

3. Separation of Logic and Control 

Closely related to the non-procedural notion of 
programming ia the notion of a logic component and a control 
component within the language [Ref. 8] . The control 
structures of conventional languages determine the order in 
which actions within the program take place. The fact that 
statements within that program must be executed in a 
specified order to ensure correctness illustrates the 
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interrelationship of those control structures with the 
actual logic of the program CRef . 5: p. 510] . 

Logic programming, on the other hand, allows a much 
greater separation of logic and control . Since the order of 
the clauses of a logic program has no effect upon the 
correctness of the program, the meaning of the program is 
tied to the logical relationship of the program clauses, not 
the order in which they are executed CRef. 2, S, S3. 

This separation of logic and control introduces the 
notion of separate analysis. Logical analysis is a concern 
for the correctness of the program, whereas, control 
analysis is a concern with the efficiency of the program 
CRef. 5, 8]. 

An obvious advantage of this separation, with regard 
to logic programming, is that the programmer can focus 
attention upon the details of the logic component when 
concerned with program correctness. Once a correct program 
has been established, the programmer can then focus upon the 
control component for efficiency considerations. This 
disjoint analysis simplifies the programmer's task by 
removing the previously dependent relationships between the 
two components. 

E. DISADVANTAGES 

Although predicate logic offers some advantages to the 
programmer in terms of representation of certain kinds of 
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knowledge, it is important to consider whether predicate 



logic provides adequate support for reasoning about that 
knowledge CRef. Id: p. 139] . 

1 . Undecidabilitv and the Halting Problem 

A ma^or drawback of predicate logic is the absence 
of a decision mechanism for dealing with the knowledge that 
can be inferred from stated assertions. Without such a 
mechanism, the resolution procedure blindly searches for a 
solution . 

Pure logic does not allow the expression of 
heuristics, which hinders the search for a path to a 
solution during the resolution process CRef. 19: p. 2313. 
Therefore the resolution strategy may allow numerous 
unnecessary and divergent paths to be taken during the 
search. This can become a grossly inefficient method of 
search . 

Additionally, given a goal statement, using 
resolution to reason backward will produce a proof if the 
proposed goal statement is, in fact, a theorem based upon 
the assertions and clauses in the logic program. However, 
there is no guarantee that such a search will terminate if 
there is no proof CRef. 19: p. 2293. This is a version of 
the halting problem and is one that the AI community has 
come to live with in their pursuit of proof methods, being 
content with a method that proves theorems even if it may 
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not halt on a non- theorem CRef. 18: p. 1393. Such 

procedures are said to be semidecidable . 

2 . Combinatorial -Explosion 

All resolution strategies are subject to the problem 
of combinatorial-explosion, since the search trees generated 
can grow very unpredictably CRef. 19: p. 2293 . Somewhat 

akin to the halting problem, it means that a success for the 
proof of an actual theorem may be prevented due to the 
tremendous size and shape of the search space. 

3 . Axiomatize All Knowledge? 

The use of logic programming toward the solution of 
all problems leads to the restriction that all knowledge 
associated with the problem must be embodied in axioms 
CRef. 19: p. 2313. Such a process might require an 

enormous effort. 

a. Heuristics 

A considerable portion of this effort can be 
attributed to the fact that there is, as mentioned above, no 
provision for heuristics in the knowledge representation. 
Therefore, such notions as best, next best, worst, etc. 
resist representation in logic and make a logical statement 
of the problem difficult or impossible. 

b. No Expression of State 

Another drawback of logic programming is the 
absence of a method for representing state transitions. 
Without such representation many problems embodied in finite 
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automata and systems programming become much more difficult 
to solve. 

4 • Implementation Considerations 

The most notable implementation of logic programming 
is PROLOG^ and the drawbacks noted here are factors that 
affect efficiency or sacrifice some of the power of the 
language in favor of more efficient execution. 

a. Backtracking and Efficiency 

As mentioned earlier^ backtracking through a 
very large search apace can be very costly to the search 
strategy, yet, for such resolution-type systems as PROLOG, 
it is very necessary. Unfortunately, it is this vast amount 
of time spent backtracking by the PROLOG interpreter that 
makes solutions to goal statements very slow in coming. 

b. Unification 

In order to regain some of this lost efficiency, 
many PROLOG implementations do not provide full unification. 
For instance, the resolution process would allow the 
unification of f<x,x) with f<y, g(y)), and would bind x to 
g(x) CRef. 7]. The problem, of course, is that the attempt 
to prune the search tree allows circularity and the 
generation of infinite loops. 

c . Assert ion /Re tract ion 

In the vein of predicate logic problem solving, 
there have been claims that PROLOG programs have no side 
effects CRef. 7]. To some degree this is true, and that 
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degree rests with those portions of PROLOG which embody the 
features of px'edicate logic. For example, the use of 
'assert' and 'retract' predicates in the language allows the 
assertion and retraction of axioms baaed upon conditions 
within the logic program. 

This violates the principle of predicate logic 
that each assertion is an independent truth. Therefore, in 
the resolution process, there are different sets of axioms 
at different points in time CRef . 3] . This dependence of 
some axioms and the addition or deletion of others diverges 
from the notion of separation of logic and control. In 
order to provide the programmer with a means to alter a 
database of facts, the advantages of separation of logic and 
control (discussed above) are sacrificed. 

F. SUMMARY 

The logic programming paradigm offers the programmer a 
high level, non-procedural approach to problem solving 
enhanced by the simple semantics of Horn clauses. The 
resolution of goal statements and the unification of 
variables within that goal is at a level below that of the 
programmer. Additionally, the inherent capability to 
separate the logic of the problem solution from the factors 
which control the solution, allows the programmer to focus 
attention upon the logical relationships of the problem 
solution and program correctness. 
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Disadvantages seem to arise from the fact that all 
knowledge is not declarative in nature and does not lend 
itself to axiomatized representation. Furthermore, certain 
control and efficiency issues are required to curb or 
contain the search of the knowledge base during the 
resolution process, and are more naturally represented 
procedural ly . 
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III. FUWCTIOMAL PROGRAMMING 



A. BACKGROUND 

The foundation of functional programming lies in the 
notion of general recursive functions, which can express any 
computable function CRef . 20; pp. 1-8] . McCarthy's "pure" 
LISP first illustrated this concept by showing that a number 
of significant programs could be expressed as pure 
functions. These pure functions in LISP, of course, operate 
on list structures, but the notion may be generalized to 
other structures. 

The importance of the recursive function concept is the 
impact that it has on the nature of programming. In 
conventional languages imperative statements are used to 
alter control flow and update memory. These statements (as 
mentioned in chapter 2) are dependent upon the order in 
which they are executed. The recursive use of pure 
functions eliminates the requirement for these imperative 
statements and, as a result, la often called "assignment- 
less" or "variable-less" programming. This "value-oriented" 
program-ming is based upon the use of pure expressions 
(discussed below) and offers the advantages of arithmetic 
and algebraic expressions to the programming language CRef. 

20 ; p . 1 - 1 ] . 
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Probably one of the Most critical attacks upon the 
conventional programming languages of the von Neumann style 
came from Backus' Turing Award Lecture, where he describes 
them as “fat and flabby" CRef. 3: p. 614]. His criticism of 
the framework, the "word-at-a-time" programming, and the 
lack of useful mathematical properties of conventional 
programming languages [Ref. 3: p. 617] led to the design of 
his Functional Programming <FP> System. 

An Important contribution In Backus' FP paradigm Is 
the emphasis on the use of functionals (described below) . 
The use of functionals allows the programmer to raise 
himself above the recursive nature of the function by 
providing a higher level of abstraction. At this higher 
level, the programs can be made more understandable and 
thereby much easier to maintain. 

B. EXPRESSIONS 

Expressions may be arithmetic, relational, or boolean, 
as Illustrated In Figure 3.1. In conventional 



arithmetic : 
relational : 
boolean : 



(a b> • c 

a b = O ' 

-(a V b) 



Figure 3.1 Types of Expressions 
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languages these types of expressions appear on the right- 
hand side of an assignment statement. By eliminating the 
use of the assignment statement we can concern ourselves 
with “pure" expressions and the properties associated with 
them CRef . 27: p. 2Q1 , These properties are listed in 
Figure 3.2 and several are discussed below. 



• value is independent of the evaluation 
order 

•• referential transparency 

• no side effects 

» Inputs to an operation are obvious in 
the written form 

» effects of an operation are obvious in 
the written form 



Figure 3.2 Properties of Pure Expressions 

1 . Evaluation Order Independence 

An Important property of pure expressions is the 
fact that within a given context, an expression has the same 
value regardless of the order in which it is evaluated. In 
fact, the evaluation of subexpressions within a given 
expression will not effect the evaluation of other 
subexpressions, and the order in which they are evaluated 
will not alter the final value of the overall expression. 
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This independence o£ evaluation order (also called 
the Church-Rosser property CRe£. 20: p. 1-3] ia illustrated 
in Figure 3.3. Here a pure expression (with subexpressions) 
is shown in tree fora, where the evaluation begins at the 
leaves of the tree. As soon as the leaves below an operator 
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/ \ 
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/ \ / \ 
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/\ 
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d e 



(a ♦ b) • (c » (d - e)) 



Figure 3.3 Pure Expression as a Tree 



node have values, that operator can be applied to those 
values and that subexpression is evaluated. Once evaluated, 
those subexpressions, as in this example, n^ay become one of 
the arguments to another operator. Note that whether the 
operator or the operator is evaluated first does not 

alter the value of the entire expression. 
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The Importance of context can be illustrated by an 
“Impure** expression, as in figure 3.4, where assignments to 
variables can be made. If memory outside the context is 
allowed to be altered, then the expression is not “pure** and 
side effects can result. In this case the value of the 
variable **a“ can be altered by the evaluation of the 
function call. 



a b « F(c) 

where F<z: integer) : integer 
begin 
a ;= O; 

F = z » z 
end; 



Figure 3.4 Impure Expression 

2 . Referential Transparency 

The property that the replacement of an expression 
(or subexpression) by its value is entirely independent of 
the surrounding expression in which it occurs is called 
referential transparency CRef. 20; p. 1-33. This property 
means that having evaluated an expression, it need not be 
evaluated again. This provides the universal ability to 
substitute equals for equals within a given context. 

For example, given the context b=3 and c=4 for the 
expression in' Figure 3.5, referential transparency means 
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that, having evaluated (b c) to the nunber 7 



the 



substitution of 7 for the other occurence of (b * c> will 
not affect the value of the overall expression. 
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/ \ / \ 
b c b c 

<a » <b ♦ c)> « (d » <b ♦ c) ) 



Figure 3.5 Pure Expression as a Tree 



C. FUNCTIONS 

Hatheaatical mappings from inputs to outputs are "pure** 
functions. Such pure functions are the and 

operators of the pure expression in Figure 3.4. The results 
of these operations depends only upon the inputs. In fact, 
the notions of pure expressions and pure functions form an 
Interesting dependency. In order for an expression to be 
pure (thus having the properties stated above) it must 
consist of pure functions. Additionally, if functions can 
be constructed with pure expressions (containing no 
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explicit, or hidden eeeignment etetements) 



then the 



function will retain the properties of pure expressions 
[Ref. 20: p. 1-53. 

1 . Function Application 

An applicative program takes the form of an 
expression that consists of the application of pure 
functions to their arguments. Thus function application is 
the fundamental operation of applicative programming and is 
illustrated, in Figure 3.6, by the prefix function form of 
the expression in Figure 3.5. 



times ( (times<plus(b,c> ,a> > , (times<plus(b,c> ,d> > > 



Figure 3.6 Prefix Form 

Within the applicative programming language 
functions may be defined explicitly, conditionally, 
recursively, or as the composition of other functions. The 
important point, however, is that these functions operate 
only on data (characters, numbers, etc.). 

2 . Functionals 

In order to provide a higher level of abstraction, 
functionals are functions that take other functions as 
arguments. Functionals result from Identifying recurring 
patterns in function definitions and abstracting them to a 
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higher level. The "nap” functional Is an excellent example, 
alnce, it accepts functions such as "times", "plus", etc. 
and maps them onto a list of ordered pairs. Such a 
functional eliminates the requirement to explicitly define 
"map_tlmes", "map_plus", etc. functions. 

Functional programming, then, is a form of applica- 
tive programming that makes extensive use of functionals. 
Not only does it simplify the programming process (fewer 
explicitly defined functions), but also offers additional 
properties which are listed in Figure 3.7 CRef . 27: p. 301 . 



• easy to use existing functions to build I 

new ones I 

• easy to combine functions using composition \ 

• subject to algebraic manipulation I 

« easier to prove correct I 

• easier to understand I 



Figure 3.7 Properties of Functional Programs 
D. PROOF OF CORRECTNESS 

The mathematical properties of functional , programming 
lend themselves to much more straightforward proof of 
correctness than either imperative languages or logic-based 
languages. Most often, the recursive function definitions 
of the functional program can be individually proved by 
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induction. Additionally, the functional programs themselves 
are subject to algebraic manipulation. A detailed analysis 
of such algebraic properties is presented in Backus' Turing 
Award Paper CRef . 3] . 

A comparison of Hoare's axiomatic model of correctness 
CRef. 28] with that of Mill's functional model of 
correctness CRef. 29] helps to illustrate this more 
straightforward proof of correctness method. 

1 . Hoare's Axiomatic Model 

Hoare's axiomatic model of correctness uses the 

notation 

(P) S (Q) 

to state the required connection between the input assertion 
P, output assertion Q, and the program (or part of a 
program) S. Partial correctness of program S results if and 
only if for every substitution of values which makes P true, 
then after execution of S, Q must be true. Total correct- 
ness results if it is proven that if P is true then S 
terminates CRef. 21] . Hoare's rules of inference, very 
similar to the rules of predicate logic, are used to prove 
correctness of particular programs. By assuming the pre- 
and postassertions of every program statement, as well as 
the program itself, the rules of Inference are used on each 
piece of the hierarchy to establish the proof. The problems 
arise from the fact that most statements of a program do not 
annotate their pre- and postconditions and that the proof of 
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Iterative portions of the program requires recognition of a 
"loop invariant" that is often difficult to ascertain. 
CRef. 21]. 

2. Mill*s Functional Model 

Hill's functional model of correctness states the 
intended function of a program as a functional abstraction 
which summarizes the outcomes of the program (or part under 
consideration) . This functional abstraction is independent 
of the control structures and data operations and reduces 
the question of correctness to one of function composition 
and function equivalence CRef. 21] . Partial correctness of 
program S means that "with respect to function F, every 
argument X, for which F is defined and F(X)=Y, then if 
program S is executed with initial input vector X, its final 
output vector is Y." Total correctness is proven by showing 
that if X is in the domain of F then S terminates CRef. 21] . 
The problem of determination of the loop Invariant is 
minimized since the intended function of the loop may be 
easily converted to a loop invariant . The problem still 
remains that in most conventional programming languages most 
statements of the program do not annotate their function. 

E. ADVANTAGES 

1 . Higher Level of Abstraction 

The advantages to be gained by functional program- 
ming are somewhat analagous to the advantages of structured 
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programming. The higher level of abstraction afforded by 
"goto-leaa** programming makes it easier to reason about and 
understand programs. The gotoa exist at a lower level of 
abstraction and the programmer is not burdened with those 
details. Similarly, the ‘‘assignment-* less" property of 
functional programming encourages an even higher level of 
abstraction, providing a more systematic derivation of 
programs and resulting in greater understandability 
[Ref. 20: p. 3-4]. Assignments, of course, exist but are 
hidden from the higher level of abstraction. 

Additionally, the functionals within the language 
provide a mechanism for achieving an even higher level of 
abstraction. Common patterns among user-defined functions 
can be abstracted out, named, and thereafter referred to 
without concern for the underlying function composition. 

2 . Mo Side Effects 

Many of the side effects associated with imperative 
programs result from the assignment statement and its use in 
altering variables (local and non-local). This results in 
hidden interfaces within the program, which degrade both 
program correctness and understandability. In functional 
programming the assignment statement is eliminated and the 
interfaces manifest themselves in the expressions of the 
program. This means that the input-output connections of 
the subexpressions within an expression are visually obvious 
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(Ref. 20: p. 1-4] end confer no hidden interfaces or side 

effects • 

3 • Verification and Proof Techniques 

The functional model has several advantages over the 
axiomatic approach. By stating specifications and sub- 
specifications as functions from an input space to an output 
space^ the functional model is a mathematical model in the 
strictest sense. The axiomatic approach organizes such 
specifications into Boolean functions represented by 
assertions on program variables^ assertions given in terms 
of the relationship of the variables involved. The 

functional approach is in terms of the relationship of the 
two value sets involved. This means that the axiomatic 
approach maps from the current values of the variables into 
the two-tuple CTrue^ False] instead of the more mathematical 
functional model which maps from the input value apace to 
the output value space. Another advantage is that changes 
in a program that do not affect another program segment do 
not require a new proof of correctness for that segment. 
This results from the fact that the proof of a functional 
specification is in terms of the behavior of the program 
statement independent of the history of variables in the 
segment. The assertions of the axiomatic approach, however, 
are restricted by variable history and Interdependence with 
other variables (Ref. 213 . Additionally, different 

implementations of a particular specification can be 
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substituted without requiring new proofs of other program 
segments. 

Functional programming and the functional model 
described go hand-in-hand toward meeting the goals of 
structured programming. The decomposition of the larger 
programming structure into simpler structures (stepwise 
refinement) is easily afforded with functional programming 
in which larger programs or functions are merely 
compositions of simpler functions. The problem mentioned 
above regarding conventional languages and how each 
statement rarely annotates its function is eliminated with 
functional programming. Therefore, the functional program 
lends itself to proof of correctness with the discussed 
model in a convenient manner. 

4 . Parallelism 

The ability to perform parallel execution in 

functional programming is a direct result of the property of 

evaluation order Independence inherited from pure 

expressions. The various nonoverlapping subexpressions 

within an expression can be evaluated simultaneously since 
the evaluation of one is not dependent upon the evaluation 
of another. Therefore, a multiprocessor could assign 
various processors to evaluate different parts of an 

expression in parallel. 

Unlike conventional languages which require the 
programmer to identify the portions of a program which can 
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be run concurrently, a functional language can handle as 
many processors as there are subexpressions to evaluate, and 
the order in which the processors are assigned, or 
subexpressions are evaluated will not alter the final 
evaluation (it may, of course, affect the efficiency of 
execution) . 

F. DISADVANTAGES 

1 . Limited Problem Domain 

Although the mathematical properties of functional 
programming offer advantages, certain tradeoffs do result 
from those properties. These tradeoffs have a limiting 
effect upon the problem domain to which functional 
programming solutions are practical, or even feasible. 

Functional programming provides no notion of state 
nor does it provide any notion of time. This weakness in 
maintaining temporal relations restricts the use of 
functional programming for such state-oriented applications 
as operating systems, database management, or discrete 
simulation . 

2 . Recursion and Inefficiency 

The recursive function definition is an important 
component within a functional programming language and is 
probably the most expensive. The expense of numerous 
recursive calls can be minimized if the hardware support can 
take advantage of the parallelism afforded by the language. 
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Unfortunately, such multiprocessor support for functional 
languages is not widespread and the use of such a language 
as "pure” LISP on a uniprocessor can be very alow depending 
upon the nested levels of recursion. Without the support 
for parallel execution, efficiency can quickly become a 
major factor in the ef f ectiveness of the programming 
language . 

3 . Industry Resistance to Change 

As with most new concepts, the resistance to change 
surfaces whenever the status quo is threatened. Moat of 
industry is still tied to the von Neumann architecture and 
"mind set" (both financially and intellectually). Until the 
decisionmakers within the industrial complex are convinced 
that the advantages afforded by new concepts will outweigh 
the expenditure in time, personnel training, and money, 
these new concepts will remain at the theoretical or 
experimental level . 

G. SUMMARY 

The functional programming paradigm provides the 
programmer with a very high level of abstraction, making it 
easier to reason about and understand programs. In contrast 
to von Neumann languages, functional languages are free from 
side effects resulting from heavy dependence upon the 
assignment statement. Additionally, the non-sequential 
nature of functional programming, based upon the property of 
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evaluation order independence, lends itself to parallel 
execution in a multi-processor environment. 

The disadvantages of the functional programming paradigm 
rest with its somewhat limited problem domain, because of 
its weakness in representing temporal relationships. 
Although functional languages lend themselves to parallel 
execution, without more effective use, in terms of hardware 
support, of the parallel nature of the language, the cost of 
numerous recursive calls is inefficiency. 
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IV. FEASIBILITY OF AN INTEGRATED LANGUAGE 



A. PROCEDURAL AND DECLARATIVE COMPONENTS 



Having 


described both the 


logic programming 


and 


functional 


programming paradigms 


, we now 


consider 


the 


feasibility 


of a language which 


integrates 


some of 


the 



features of both programming paradigms. It should be noted 
here that both logic programming and functional programming 
are within a classification of programming which MacLennan 
refers to as ”value-or iented** programming CRef . 221 . He 
includes equational programming CRef. 23] and relational 
programming as well CRef. 24], but here we consider 
equational programming a more restrictive form of functional 
programming and relational programming a form of functional 
programming (since a function is a relation) which can deal 
with multi-valued functions. The focus, then, is on the 
feasibility of integrating a procedural component 
(functional programming) and a declarative component (logic 
programming) within a single language. 

The non-procedural aspects of logic programming make it 
very advantageous for stating facts (or axioms) from which 
knowledge can be inferred, or about which queries can be 
made. Yet it is unnatural to define everything 
declaratively . For example, moat PROLOG implementations 
define numbers and the operations on them procedurally . In 
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such instances it is not only unnatural to define them 
declaratively ^ it ia leaa efficient CRef . 253 • 

By contrasty the non-declarative aspect of functional 
programming can make the manipulation of information in a 
knowledge base very tedious and inconvenient. Since the 

search of such a knowledge base is explicit^ the programmer 
must define functions that perform the search or comparisons 
required. These contrasting aspects of both programming 
paradigms will be illustrated and explained in the following 
examples • 

B. EXAMPLES OF CONTRAST 

1 . Declarative Versus Procedural 

Consider the PROLOG program in Figure 4.1 and the 
LISP program in Figure 4.2. The program in figure 4.1 can 
be used to find out such information as the annual salary^ 
weekly tax, etc. of an employee asserted in the database. 
By merely satisfying the goal 

weekly_tax( John_Doe, X) 

the system will perform the necessary resolution, 
backtracking and unification to produce the weekly tax of 
John Doe. Similarly, the LISP program in Figure 4.2 will 
return that individuals weekly tax when the function 

weekly_tax ( John_Doe) 

is called. In comparison, note that although the three 
clauses for weekly^tax in the logic program can be defined 
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by one function (with a conditional) in the functional 
program, both programs perform the same function and their 
difference is primarily syntactical. 



weekly_salary( John_Doe,500) . 
weekly_salary< Jim_Jones,350> . 

• 

annual_salary (X, Y) <-- weekly_salary <X,2) , 

Y is <Z * 48) . 

weekly_tax(X, Y) <-- annual_salary (X,2) , 2 >= 20000, 

weekly_salary (X , B) , 

Y is (B * .06) . 

weekly_tax(X, Y) <-- annual_salary (X,2) , 2 >= 10000, 

2 < 20000, weekly_salary <X,B) , 

Y is (B * .04) . 

weekly_tax (X , Y) <-- annual_aalary (X,2) , 2 < 10000, 

weekly_salary (X , B) , 

Y is <B * .02). 



Figure 4.1 PROLOG Program 

However, a query to the logic program such as 
<-- weekly_tax(X, Y) , weekly_tax (2, Y) , 
which will return all pairs of employees that pay the same 
weekly tax, la not possible in the functional program 
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without defining a nested function that explicitly checks 
the database against a conditional expression and constructs 
a new list with the results. 



<SETQ weekly_salary (cons 'John_Doe 500) 

(cons 'Jia_Jones 350 ...)) 

DEFUN ( ( 

( weekly _tax ( Name) 

(PROG (WS) 

(SETQ WS (cdr (sassoc Name weekly_salary ) ) ) 
(COND 

(( GEQ 20000 (TIMES 48 WS )) 

(TIMES .06 WS ) 

(( GEQ 10000 (TIMES 48 WS )) 

(TIMES .04 WS ) 

(T (TIMES .02 WS )) )) )) 



Figure 4.2 LISP Program 
2. PROLOG Use of Cut 

This illustrates that the pattern matching in 
PROLOG, resulting from the resolution of subgoala, is an 
advantage during the search of the database, because the 
method of search is at a lower level than that of the 
program. However, the same PROLOG implementation of logic 
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programming that, offers this abstraction also requires the 
use of the "cut" symbol. The cut symbol is a means of 
halting unnecessary or unwanted backtracking. Its use 
within the clauses of a logic program requires the 
programmer to be Intimately familiar with the method of 
backtracking, or side effects may be introduced into the 
program. This is because the cut symbol alters the way 
backtracking works after its use. The effect of the cut is 
to remove the place markers for certain goals so that they 
cannot be resatisfied, and commits the system to every 
unification made since that clause was entered CRef. 2: pp. 
64-6S] . 

The side effects of using the cut symbol arise from 
the fact that a clause may be used in a manner for which it 
was not intended. For instance, consider the two clauses: 
appendC C] ,X,X) <-- "cut". 

' append( CA I B] ,C, CA I D] > <-- append(B,C,D> . 
where the cut prevents unnecessary backtracking. When 
resolving goals like 

<-- appendC Ca,b,c] , Cd,e] ,X) 



or 



<-- appendC Ca,b,c3 ,X,Y> 

the cut works as intended and is appropriate from an 
efficiency standpoint. However, if the goal 

< - - appendCX, Y, Ca,b,c] ) 

is resolved, it would be matched and unified with the first 
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clause yielding X - C] and Y ^ Ca,b,cl . The cut would 
prevent any further resolution and no other answers could be 
generated even though others existed CRef . 2: pp. 65-66] . 
As the cut is placed deeper in the body of a clause, to 
freeze unification made to that point, the side effects 
become more difficult for the programmer to predict. 

In an attempt to provide a means of controlling the 
cost of backtracking, the PROLOG implementation of logic 
programming requires the programmer to be aware of the 
underlying backtracking mechanism, introduces possible side 
effects, and negates the advantage gained by keeping the 
resolution mechanism at a lower level than that of the 
programmer . 

C. INTEGRATION 

The previous examples help to Illustrate certain 
problems and inadequacies that result from either a strictly 
procedural approach to programming, or from a declarative 
approach interspersed with procedural features for efficient 
control. The PROLOG implementation of logic programming is 
a somewhat integrated approach, though to a very small 
degree, and the major problems with that approach have been 
described. The existence, and utility, of PROLOG gives some 
credence, then, to the feasibility of an integrated 
language. However, the problems with PROLOG seem to stem 
from the features of the language which are somewhat foreign 



to Kowalski's concepts (described in chapter 2) of separa- 
tion of logic and control , and LUSH resolution of Horn 
clauses. 

In keeping with these concepts, a procedural component, 
namely functional programming, can provide the control 
characteristics for an effective and efficient declarative 
component, as well as provide a means for representing non- 
declarative knowledge. 

1 . Procedural Call From Declarative Component 

To illustrate this notion, consider first the 
ability to call the procedural component from the 
declarative component. For example, the logic program in 
Figure 4.1 used three clauses to define weekly_tax. The 



weekly_tax(X, Y) <-- weekly_salary (X,B) , 

annual_salary (X,Z) , 

Y is #(COND 

<(GEQ 20000 Z) 

(TIMES .06 B) 

((GEO 10000 Z) 

(TIMES .04 B) 

(T (TIMES .02 B) )) >) 



Figure 4.3 Call to Procedural Component 
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advantages gained by backtracking within a single clause 
becone cumber done , tedious, and expensive when backtracking 
must occur through several clauses that have the same head. 
In an integrated approach, the ability to define weekly_tax 
(Figure 4.3) with a procedural call (denoted by the "#** 
symbol), which performs the conditional control, allows the 
instantiated values of the variables Z and B, unified 
through resolution, to be used in the function to 
instantiate the variable Y. The requirement for three 
clauses with the same head has been reduced to one clause 
where resolution is no longer needlessly replicated. 

In such an example, note that the functional call 
from the declarative component merely returns the value of 
the evaluated function. Such a function can be evaluated by 
theprocedural interpreter and is regarded as a standard 
functional expression. 

2 . Declarative Call From Procedural Component 

A call to the declarative component from the 
procedural component, on the other hand, requires a 
rethinking of the resolution process. For example. Figure 
4.4 Illustrates such a call in an attempt to use the 
advantages of resolution, instead of explicitly defining a 
function, to search the knowledge base and perform the 
unifications which provide a solution. But in this case the 
call to the declarative component cannot merely return the 
result of an evaluated expression. In this simple example. 
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<de£un append < L H > 

(cond 

<< null L) M ) 

(T (cons (car L) (append (cdr L> H > ) ) > > 

append ( #(weekly_Tax(X,30) , weekly_tax( Y,30) ) , 
' (John Smith) ) 



Figure 4.4 Call to Declarative Component 

the procedural component expects the declarative call to 
return a list of employees which pay 30 dollars in weekly 
tax. However, suppose the uninstantiated variable Z was in 
place of the 30. The resulting list of employees would be 
dependent upon the various instantiations of Z, and without 
knowing which employees were associated with those values of 
Z, the resulting list would be meaningless. What about a 3- 
tuple list which yields the X, Y, and Z instantiations of 
every solution? Such a list could become a rather large 
list of permutations with, possibly, redundant information. 
Here the results to be returned are more complicated and 
require modification to the resolution mechanism within the 
declarative interpreter. 

Such modification, discussed in the following chapter, 
is based upon two Important observations that arise from 
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the previous example: 

Queries (calls to the declarative component) must be 
qualified. Qualifications such as ‘'all', 'any', etc. 
must be made explicitly In the query. 

Unification must be baaed upon the given context (or 
environment) In which the declarative call is made. A 
context la a list of unifications (or bindings) which 
provide a constraint upon the resolution of the 
declarative clause. 

These observations form the foundation upon which the 
features of a truly Integrated language can be described. 
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V. FEATURES OF AN INTEGRATED LANGUAGE 



A. SYNTAX ISSUES DEFERRED 

Whether the syntax of an integrated language should be 
uniform (either functionally baaed or logically based), or 
whether it should be mixed, is an issue that will be 
deferred at this point. The intention is to describe the 
important features of an integrated language and discuss the 
modifications required of the resolution process within the 
declarative component. In keeping with the examples of the 
previous chapter, the use of PROLOG and LISP syntax can 
adequately represent the points to be made, and the mixed 
syntax will better illustrate the transfer of control from 
procedural interpretation to declarative, and vice versa. 

With this transfer in mind, the •*#" symbol will 
represent the transfer of control from one component to the 
other. The results from a procedural call (function 
application) within the declarative component must be the 
value of the evaluated function, and will be used to 
instantiate (or unify) a variable within the clause. The 
results from a declarative call (resolution process) within 
the procedural component, on the other hand, must return a 
list of solutions to the query. Each solution is itself a 
list of variable bindings that provide a solution to the 
given query. 



53 



B. QUALIFICATION OF A QUERY 

Aa deacribed in the prevloua chapter, a call to the 
declarative component muat be qualified to enaure that 
expected, and meaningful, reaulta are returned to the 
procedural component. In general, the programmer may 
require aeveral different typea of reaulta from the 
declarative component. In aome Inatancea the programmer may 
require a Hat of all poaalble aolutlona to a given query. 
But In other Inatancea, the programmer might require only a 
limited number (or even one) of all the poaalble aolutlona. 

Baaed upon the functlona deacribed In Roblnaon'a LOGLISP 
[Ref. 26] theae quallflera can be repreaented by the 
following : 

ALL - returna, aa a reault of the declarative call, a 
Hat of all tuplea which aatiafy the query within 
the conatralnta of the current context (detaila of 
reaolution within a context are in a later section) . 

ANY K - returna a Hat with no more than K of the tuplea 
returned by ALL. 

With theae two quallflera as the foundation, the 
programmer may use the functional component of the language 
to define, for convenience, functlona which perform special, 
or redundant, cases of the basic qualifiers. For example, 
the qualification ANY 1 to the given goal statement, will 
return a Hat containing the single list of variable 
bindings that provides one solution. A function THE, which 
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will return those bindings in a single list, and may be 
defined by 

THE (Q) = #ANY 1 <Q) . 

C. QUERIES AND THEIR CONTEXT 

Associated with each query, or goal statement to be 
resolved, is an implicit context within which certain 
constraints are placed upon the resolution process. These 
constraints are variables which are already bound to values. 
If variables that are part of the goal statement are already 
bound, then those variables cannot be re-instantiated during 
the resolution process. For those variables that are not 
defined in the current context of the query, they are 
considered free variables and can be instantiated (or bound) 
during the resolution process. 

1 . Context Description 

The context associated with each query contains all 
bound variables, of local scope, which may be bound to terms 
or to other variables. The fact that variables may be bound 
to other variables makes the unification somewhat more 
complicated, but is necessary to allow the resolution of the 
goal to progress as intended. It should be noted, however, 
that such indirect binding must eventually terminate with a 
binding to a term within that context. 

The bindings within a given context can be denoted 
in a manner that lends itself to LUSH resolution (see 
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Chapter 2) , which will simplify the checking of variables 
within that context. For example, 

X <-- Y 
Y <-- a 
2 <-- b 

represents the context (variables in uppercase, terms in 
lowercase) of a given query Q, within which X is bound to Y, 
Y, in turn, is bound to “a", and 2 is bound to **b*'. 
Therefore, a query such as 

P(T,X,V) 

would have two free variables, T and V, and the variable X 
would be bound to the term "a" during each resolution 
process in the search for a solution. 

2 . Context Algorithm 

For a given query Q and its associated context C, 
the constraints placed upon the resolution of 0 are 
represented by the variables that are already bound. The 
following algorithm is concerned with a query of the form 

*** 

where 

P^CXj^.X^, ... ,x^) 

represents each predicate, and C is the context of the 
query . 
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Algorithm: 

repeat 

for (each variable of every predicate in Q) 

reaolve C(X^> (perform LUSH resolution on ) 

(database C } 

if C(X > * nil 
— 3 

then X^ is a free variable and do nothing 

else instantiate X to term t. . returned from 
3 k 

resolution of C(X^)» within the query Q 
place the binding tuple in the list that 
will contain all such bindings 
until (all variables are checked) . 

Once these constraints have been placed upon Q, the 
query can then be resolved (subject to the modifications 
described below) . 

D. MODIFICATION TO THE RESOLUTION PROCESS 

Most PROLOG implementations provide for the resolution 
of goal statements baaed upon the LUSH resolution described 
in Chapter 2. When a programmer makes a query to the 
knowledge base and a solution is provided, the programmer 
may then induce a failure (usually by hitting return) which 
invokes backtracking in search of another distinct solution. 
For our integration purposes, the qualifiers ALL and ANY K 
determines at the outset whether one, more, or all solutions 
are required. 
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From the above context algorithm, the constraints placed 
upon the query Q are defined in the list of bindings S^. 
This list contains the instantiated variables of Q (if any), 
and have been so instantiated in Q. The query Q may now be 
resolved by the declarative component, the PROLOG 
interpreter for this example, until a solution is found or a 
failure is obtained. Given a solution is found, let the 
associated list of all solutions be denoted by 



S “ ^ ^1 ^ ^2 ^ ••• ***^^m^ 

where is the first solution obtained in the resolution 
process . 

In constructing such a solution, the following algorithm 
represents the modification to the resolution mechanism of 
the declarative interpreter that will allow its 
construction. The algorithm modifies the basic declarative 
interpreter such that the entire results of the qualified 
query are returned as a list of bindings which satisfy that 
query. Once the declarative resolution mechanism returns a 
failure, there are no more solutions to be obtained, and the 
search is halted. If it is the first attempt at a solution, 
then the empty list is returned, otherwise the list of 
solutions to that point are returned. 

Algorithm : 

Given the qualifier to the query, the query Q, and the 

constraint bindings in C, 
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First i, 
repeat 

resolve Q 

1£ FAIL {from resolution of Q) 

then if. i = 1 

then * <) 

place S. in S 
1 

HALT; 

else (have a solution) 

place binding tuples of solution in a list 

(returned from resolution of Q) 

append this list to 

(to Include initialization bindings) 

let denote new list 

place S. in S 
1 

induce FAILURE (standard PROLOG mechanism to ) 

(search for another solution ) 
if qualifier = ANY K (check qualifier) 
then if i >= K 

then HALT; 

Next i 
until HALT 
return S. 

Notice that the binding constraints placed upon the 
initial query must be explicitly included with the solution 
bindings resulting from the resolution of 0. These bindings 
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were saved in when the constraint instantiations were 

nade in Q. They must be returned as part of solutions in S 
since they provide variable bindings that are part of the 
solution . 

Although there is no explicit check for the ALL 
qualifier in the algorithm^ it is felt that its syntactic 
inclusion^ as part of the qualification to the query, will 
provide more regularity and structure to the integration 
interface. 

E. AN INTEGRATION EXAMPLE 

To illustrate the extensibility offered the programmer 

from the functional component, consider the function in 

Figure 5.1. This function takes the list of solutions 

obtained from the declarative call, represented by 

S = ( S .... S ) 

12 n 

where 

Si = ((Xi t^) (X^ t^) ... <X^ 

and allows the programmer to specify which variables within 
the declarative call will be returned as meaningful results. 
This general function provides the programmer considerable 
flexibility in utilizing or manipulating the results 
obtained from the declarative call. 

For example, consider a knowledge base of facts 
concerning the armed forces of various countries, their 
mobilization status, geographical relationships, etc. 
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Return_liat = <<NLAHBDA L) 

<PROG < S VARLIST RESULTS ) 

<SETQ S (EVAL (LAST L) ) ) 

(SETQ VARLIST (LDIFFERENCE L 

(LAST L>>> 

(SETQ RESULTS 

(MAPCAR S 'LAMBDA (S^> 

(MAPCAR VARLIST 'LAMBDA (X) 
(ASSOC X S^ ) ) ) ) > ) 



Figure 5.1 Function Definition 
Then a question of the form 

"Which Warsaw Pact countries have exercised armored 
divisions within the past six months, and what divisions 
were they?" 

could be handled by the following function (which makes a 
call to the declarative component) : 

Return_list (X Y (#ALL (country(X), warsaw_pact (X) , 

armored_division(X,Y ) , 
aobillze(Y,D) , D > 2 ))) 

Here we assume that the variable 2, representing a Julian 
date, has been bound outside the function call (perhaps 
based upon a previous query regarding information within the 
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last six months) . Therefore, the variable Z is in the 
current context C, is instantiated in the query, and 
saved in S^, based upon the context algorithm described 
above. 

Turning to the function in Figure 5.1, the solutions 
returned in S (based upon the modified resolution algorithm 
above) are, in effect, associated with the variables 
explicitly listed as an argument to Return_list, and only 
these values are returned. In this case the variables X and 
y are listed, and may be exemplified by results such as 

((Poland Fifth_arraored> (Poland Seventh_armored) 
(Hungary Second_armored) (DDR Second_armored) ) . 
Other queries can be made to the declarative component 
based upon the solutions provided by the previous results. 
For instance, a follow-on question like 

"Where 1s the Second armored division of the DDR 
currently located?" 

could be resolved by first instantiating variables X and Y 
outside the query (possibly using SETQ) and using the 
function Return_list again with a different call to the 
declarative component. Therefore, the function call 

Return_list (W (#ANY 1 (armored_di vision (X , Y) , 

current_location(Y,W) ) ) ) 

would return the current location (given such information is 
in the knowledge base) of the instantiated armored division. 
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F. SUMMARY 



The previous examples Illustrate the notion of a 
procedural component providing the control for logical 
relationships In the declarative component of an Integrated 
language. They demonstrate the concept of resolution within 
a context, described above, and Illustrate the flexibility 
provided the programmer. In that user defined functions can 
be created to best utilize or manipulate the results 
provided by a query to the declarative component. 

By strict enforcement of the separation of logic and 
control, the use of the "cut" symbol can be eliminated. Its 
use in PROLOG is based upon the fact that the programmer is 
required to provide control mechanisms within the logical 
relationships that are created. A logical relationship that 
is so complex that a cut is used by the programmer (to 
effectively save information to that point by halting the 
backtracking mechanism) must be simplified in a way that 
makes each logical relationship a separate entity. 
Therefore, the programmer still has the burden of 
understanding the manner and method with which logical 
relationships are defined In the declarative component, but, 
more importantly, the requirement to understand the low- 
level details of backtracking Is removed. 
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VI 



CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

The previous chapter described the initial features to 
be considered in the integration of logic programming and 
functional programming. Presented has been an argument that 
an integrated language better supports Kowalski's notion of 
separation of logic and control CRef . . This argument has 
been baaed upon the idea that declarative aorta of knowledge 
(facts and logical relationships) should be expressed in a 
declarative way, and that procedural sorts of knowledge 
(manipulation, control, and utilization of data) should be 
expressed in a procedural way. 

Toward this end, the declarative component of an 
integrated language establishes a knowledge base of facts 
(or assertions) as well as rules for associating those 
facts, determining logical relationships among them, or even 
inferring new knowledge and relationships. The procedural 
component, then, is the interactive tool for explicitly 
controlling those logical relationships and the knowledge 
base of facts upon which they are built. 

The explicit control afforded by the procedural 
component has eliminated redundant and unnecessary 
backtracking . Since multiple rules are no longer required 
to define a single logical relationship, redundant 
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backtracking through the bodies of several clauses with the 
same head is avoided. This allows the programmer to 
associate one clause with one logical relationship, 
providing clearer understanding and easier modification and 
maintenance . 

The necessary control for utilizing and manipulating 
results obtained from a query to the declarative knowledge 
base is provided by the programmer. This control, however, 
is no longer at the low level required when using the "cut" 
symbol. The control is now concerned with logical 
relationships and avoids the side effects resulting from the 
use of the "cut". 

Additionally, the programmer is no longer concerned with 
explicitly defining the search of a knowledge base of 
assertions and rules. By using the procedural component to 
manipulate the results obtained from a query to the 
declarative component, the programmer can focus on higher- 
level issues of interrelationships among the results of such 
a query, not on the lower-level details of how that search 
was performed. 

All of these conclusions support the ideas of 
abstraction, higher-level focus, and information hiding, 
discussed in Chapters 1 through 4. The argument for an 
integrated language, based upon the features described in 
Chapter 5, is conceptually sound, and has further supported 
the idea that representing varied forms of 
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knowledge in a strictly procedural, or strictly declarative, 
manner forces the programmer to contort the representation 
of one form of knowledge to fit its expression in another 
form . 

B. RECOMMENDATIONS 

Having provided a conceptual framework for the design of 
an integrated language, future emphasis should be placed 
upon more detailed design, and eventual implementation, of 
each of the procedural and declarative components of the 
language. A decision must be made regarding the choice of 
syntax <uniform or mixed) of the language, and the detailed 
features of each component must be based upon that decision. 
For instance, the choice of a functionally-based uniform 
syntax would require a redesign of the manner in which 
logical assertions and relationships are represented and 
interpreted. Such a redesign, however, may greatly simplify 
the integration interface described in the previous chapter. 

Additionally, emphasis must be placed upon issues which 
were of concern regarding each programming paradigm in and 
of itself. Such issues are efficiency considerations and 
parallelism. With regard to efficiency, both the functional 
programming language and the logic programming languages are 
Inherently slow without adequate hardware support. This 
slowness is a result of recursion in the functional language 
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and searching in the logic language. Having an integrated 
language with both features emphasizes the necessity for the 
hardware support for parallel execution. 

Fortunately, both functional programming and logic 
programming support the notion of parallel execution, and 
with adequate hardware support, an integrated language could 
provide the best features of a functionally-based procedural 
component, as well as the best features of a logically-based 
declarative component, and that la sufficiently efficient to 
provide timely calculations and results. 
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